A programmable logic device (PLD) such as a field programmable gate array (FPGA) requires configuration by the user before normal operation. Various programming systems exist that enable a user to shift in configuration data into the PLD to effect a desired logical function. There are corresponding types of elements or components that are configured by the resulting stored configuration data within the PLD. The primary component being configured may be referred to as the programmable fabric—in the case of a field programmable gate array (FPGA), the programmable fabric includes a plurality of lookup-table-based logic blocks as well as an associated routing structure. The configuration data for the programmable fabric is typically stored in a volatile FPGA memory (SRAM) and is shifted into the device through a dedicated data shift register (DSR).
The configuration process typically starts with the user translating the desired logical function that a user desired to implement on the PLD into a hardware description language (HDL) on the programming system, which is typically a PC configured with the appropriate programming software. The programming PC, through its associated software, translates the user's HDL into a netlist. This netlist is then mapped by the programming PC to the resources corresponding to the particular type of FPGA being configured. The programming system can then perform a route and place routine in which the logic elements from the user's design are assigned to corresponding resources within the FPGA being programmed. The resulting mapping is fine-tuned and debugged during a simulation stage. Once the design is deemed satisfactory, a corresponding bitstream is generated that is downloaded into the FPGA.
The placing and routing of the mapped netlist into the programmable fabric of an FPGA involves numerous choices. For example, suppose the mapped netlist requires a signal flow through a particular combination of logic gates. Because of the placing and routing flexibility in the programmable fabric, the programmable logic blocks could be relatively close to each other or relatively far from each other. The routing delay through the potential paths can thus vary considerably. This flexibility is constrained, however, by any required timing on the signal flow path. One particular type of timing requirement is known as the clock to output (typically abbreviated as the “clock to out”), which defines the delay that elapsed from the time when a clock edge arrives at an FPGA input pin to when the associated data is valid at its FPGA output pin. The clock to out requirement is generally expressed as a maximum allowed value—a given placing and routing of the mapped netlist may be able to achieve a smaller clock to out value. However, some designs also involve a minimum clock to out value, which would be the earliest time at which the FPGA could deliver the associated data to its pin. The clock to out timing may also defined with regard to a clock output from an FPGA pin. In that regard, the same clock having the clock edge that is received at the FPGA pin discussed above may propagate through a combinatorial path in a configured portion of the programmable fabric to a corresponding FPGA clock output pin. The clock to out timing requirement may then be defined as the maximum and/or minimum delay difference from when the data is valid at its output pin to when the clock is valid at its clock output pin. Conventional placing and routing software has difficulty converging to a particular placing and routing choice that satisfies such a relative delay requirement.
Accordingly, there is a need in the art for improved placing and routing software that can efficiently accommodate a relative clock to out vs. clock out timing requirement.
Embodiments of the present invention and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like reference numerals are used to identify like elements illustrated in one or more of the figures.